General Packet Radio Service (GPRS) is a set of standards designed for supporting data services on top of a GSM network. GPRS offers transparent IP services to the underlying GSM network and allows GSM networks to interface with the Internet. FIG. 1 illustrates a typical GPRS communication network 100. The GPRS communication network 100 includes GSM network nodes such as a Base Transceiver Station (BTS) 108, a Base Station Controller (BSC) 110, and a Mobile Switching Center (MSC) 122, which form the GSM core network. The GPRS communication system network also includes a Serving GPRS Support Node (SGSN) 112 connected to a Gateway GPRS Support Node (GGSN) 116 via a GPRS IP Backbone 114; these components form the GPRS core network. The GPRS network 100 provides packet data services to mobile stations 102, 104, and 106 and allows them to access data services provided by an application server 120 across the Internet 118.
When the mobile station 102, 104, or 106 powers up, it initiates GSM registration and location update procedures with a MSC/VLR 122, and GPRS registration and routing area update procedures with a Serving GPRS Support Node (SGSN) 112. These two registration processes can be combined and may be referred to as “attach.” Once attached, a mobile station carries out its location updates with the MSC/VLR 122 and its routing area updates with the SGSN 112. During the GPRS registration (GPRS attach), the mobile station 102, 104, or 106 initiates a GPRS Attach Request to be sent to the SGSN 112. The SGSN 112 authenticates the identity of the mobile station with the MSC 122, receives from the MSC 122 the authorization of services for the mobile station, and assigns a Packet Temporary Mobile Subscriber Identity (P-TMSI) to the mobile station.
When the mobile station 102, 104, or 106 attempts voice transmission, an end-to-end circuit switch connection needs to be established. When the mobile station 102, 104, or 106 attempts data transmission, no end-to-end connection is needed, but instead a Packet Data Protocol (PDP) context must first be created to allow the network to identify the operational parameters associated with data transmissions made between the mobile station and the SGSN/GGSN. A PDP context includes parameters such as a requested QoS for this particular PDP context and certain protocol configuration options. Establishment of a PDP context is handled by messaging between the mobile stations 102, 104, or 106, the SGSN 112, and the SGSN 112/GGSN 116. PDP context activation may be initiated by a mobile station, a GGSN or an SGSN, and usually involves a series of messages transmitted between the mobile station, the SGSN, and the GGSN. For example, when PDP context establishment is initiated by the mobile station 102, the mobile station 102 sends an Activate PDP Context Request message to the SGSN 112. The PDP Context Activation Request message includes a requested PDP address of the mobile station, an Access Point Name (APN), a requested NSAPI (Network Service Access Point Identifier), a requested QoS, etc. After receiving the Activate PDP Context Request message, the SGSN 112 then derives the address of the intended GGSN from the APN included in the Activation Request and sends a Create PDP Context Request message to the intended GGSN, for example, the GGSN 116. The Create PDP Context Request message includes a Tunnel Endpoint Identifier (TEID), the APN, and the requested PDP address, etc. In response, the GGSN 116 may send to the SGSN 112 a Create PDP Context Response message that includes the results of the PDP context creation. Upon receiving the PDP Context Response message from the GGSN 116, the SGSN 112 sends an Activate PDP Context Accept message to the mobile station. The Activate PDP Context Accept message may include the negotiated PDP address assigned for the mobile station, a PFI (Packet Flow Identifier) value associated with the PDP Context and an LLC SAPI (Service Access Point Identifier at the LLC layer) value. LLC SAPI identifies an access point at the LLC layer that can be used for GPRS data services.
Mobile stations often run machine-type communication (MTC) applications and are referred to as MTC devices herein. The acronym ‘MTC’ is used to refer broadly to any type of machine-type communication. Examples of MTC devices include smart meters, surveillance cameras, health monitoring devices, etc. An MTC device usually runs an MTC application and engages in machine to machine communications over a GPRS communication network with an MTC serve located on the Internet. Machine to machine communications involve no or very limited human interaction. The communication network can be based on, for example, xDSL (digital subscriber line), LTE (3GPP Long Term Evolution), LTE advanced, WiMAX (worldwide interoperability for microwave access), WLAN (wireless local area network), etc.
Because of the increasing number of MTC devices and the automated nature of MTC applications, MTC traffic is expected to place a large capacity demand on wireless communication networks, which are designed primarily for human-to-human communications. For example, for PDP context activation, at least four signaling messages (Activate PDP Context Request, Create PDP Context Request, PDP Context Response, and PDP Context Accept) are transmitted if the activation is initiated by a mobile station. More messages are involved if the activation is initiated by a GGSN or an SGSN. In a scenario in which all MTC devices located within one GPRS communication network simultaneously re-connect to the network, say, after a power outage, the communication system may be overwhelmed by the sheer number of PDP Context activation related signaling messages.
In another example, it is expected that a significant number of MTC devices will commonly transmit short MTC messages consisting of 10 or less octets of information. GPRS standards define a Single-block Packet Access procedure that does not involve the establishment of an uplink Temporary Block Flow (TBF). A TBF link is a connection at the physical layer between a mobile station and a Base Station System that is allocated temporarily for data transmission. Single-block Packet Access procedures are used by a mobile station for sending Packet Measurement Report messages. Before transmitting a measurement report message, a mobile station first sends a Packet Channel Request message on the Radio Access Channel to the BSS to request a single-block packet access without the establishment of an uplink TBF. Upon receiving the Channel Request message from the mobile station, the BSS assigns a single radio block to the mobile station and sends an Immediate Assignment message to the mobile station on the Access Grant Channel. The Immediate Assignment message contains a packet uplink resource description that includes power control parameter settings and a starting time for the first frame number of the single block. After receiving the Immediate Assignment message, the mobile station sends a Packet Measurement Report message at the start time of the assigned radio block on the Packet Data Channel. In a Single-Block Packet Access procedure, no acknowledgement by the BSS is provided and therefore no ACK/NACK messages are involved.
However, attempting to use Single-Block Packet Access procedures for MTC message transmissions requires that an MTC message together with the overhead associated with the different protocol layers in the air interface protocol stack, for example, UDP/IP/SNDCP/LLC, fit within one single radio block (22 octets if CS-1 coding is used). But the headers from the transport and network layers of the protocol stack add considerable overhead. For example, the headers for UDP/IP layers alone add 46 to 48 octets of overhead to every MTC message.
In Release 10 of its standards for Universal Mobile Telecommunications Systems (UMTS), 3GPP (3rd Generation Partnership Project) is in the process of establishing requirements for 3GPP network system improvements that support MTC. The objective of this study is to identify 3GPP network enhancements required to support a large number of MTC devices in the network and to provide necessary network enablers for MTC communication services. Specifically, transport services for MTC as provided by the 3GPP system and the related optimizations are under consideration as well as aspects needed to ensure that MTC devices, MTC servers and MTC applications do not cause network congestion or system overload. However, current mobile networks remain optimally designed for human-to-human communications and are thus less optimal for MTC applications. Also, MTC bandwidth demand (e.g. for PDP Context activation related signaling) is expected to increase significantly as the number of MTC devices serviced by a network increases. MTC devices exert payload demands in both signaling plane and transmission plane. Methods and techniques related to MTC traffic reduction in both the signaling (control) plane and data transmission (user) plane are needed to reduce system overload and improve network efficiency.